[Datenschleuder] [58]    Firewalls - Aufzucht und Pflege

Chaos Communication Congress 96 Firewalls - Aufzucht und Pflege Referenten: pirx@ccc.de, hhf@ccc.de Zu Beginn des sehr gut besuchten Workshops (selbst Fußbodenplätze waren bei den ca. 70 Besuchern am Ende ausverkauft) wurden erstmal die vier W-Fragen zu Firewalls gestellt: Warum? Wie? Was hilft's? Was hilft's nicht ? Diese sollten dann im Laufe des Workshops geklärt werden. Ron stellte zunächst einmal fest, daß es "Firewalls" als solche nicht gibt, daß zwar Geräte verkauft werden, auf denen außen Firewall draufsteht, die sich aber in Aufbau und Funktion teilweise deutlich voneinander unterscheiden. Was es gibt, sind Firewall-Prinzipien, die umgesetzt werden, aber auch noch miteinander kombiniert werden können. Warum soll man nun als Betreiber eines Netzes eine Firewall einsetzen? Eine Firewall kontrolliert die Kommunikation zwischen Rechnern des eigenen inneren Netzes mit der Außenwelt, in der Regel dem Internet, jedoch in etlichen Fällen z.B. auch innerhalb des inneren Netzes, z.B. um Daten innerhalb einzelner Abteilungen zu schützen. Angriffe, die möglicherweise auf ein Netz ausgeübt werden können, sind: * spoofing = Vortäuschen/"Faken" von IP-Adressen und Source-Route-Hacking sind heute meist nur noch zum "Tarnen" bei Hacking- und Floodingaktionen geeignet. Das Problemdabei ist: Antworten kommen nicht zurück, die Methode ist also nur für "Dialoge" geeignet, wo man weiß, was der Gegenüber antwortet * denial of service _(System kann nicht mehr benutzt werden) * Informationsdiebstahl * Zerstörung von Systemen / Daten; Datenmanipulation * Kontrolle der Nutzung * Flooding (Überschwemmen des Systems mit gefakten Paketen, die Systemleistungen zum Empfang verbrauchen). Wenn man nun den Einsatz einer Firewall für sinnvoll hält, muß man sich fragen, was man damit erreichen will, sein System "sicher" zu machen. Dafür ist es wichtig zu wissen, wie die Komunikation von einer Firewall gefiltert werden. Paketfilter: * Source Address * Destination Address * Service (Port) * Content (Inhalt; theoretisch) * Masquerrading (Beim Masquerading wird die Real-Adresse durch die eigene Adresse ersetzt und verändert die Portadresse. Die Verbindung wird in einer Tabelle mitprotokolliert, damit die Rückübersetzung der veränderten Adressen möglich ist. Für FTP in der Regel nicht möglich.) Möglich sind auch Firewalls, die auf dem Application-Layer aufbauen, z.B. durch WWW-Proxy, FTP-Proxy, Telnet Proxy, Socks. Es muß immer abgewägt werden, wie wichtig die Sicherheit ist und was sie an Aufwand und Kosten mit sich bringt. Man kann mehrere Firewalls hintereinanderschalten, auch in der Praxis werden tatsächlich bis zu 5 Firewalls hintereinandergeschaltet, die die Pakete mit unterschiedlicher Hardware und nach unterschiedlichen Kriterien filtern. Nach Adressen kann in beiden Richtungen von einer Firewall sehr einfach gefiltert werden, Service(Dienste)-Filterung ist auch gut möglich (z.B. wer darf Send-Mail betreiben, wohin darf Sendmail nicht gehen). Die Kombination von Adreß- und Dienst-Filtern ist schon sehr feingliedrig. Für den Aufbau von Firewalls lassen sich verschiedene Konzepte finden, von denen die verbreitetsten hier vorgestellt werden: 1. Konzept: Einsatz von Filtern nach verschiedenen Kategorien, z.B.: nicht mehr als bestimmte Anzahl von Paketen pro Zeit (erhöhter Zugriff), Einschränkungen beim Zeitpunkt des Verbindungsaufbaus (nicht am Wochenende). Die benötigte Hardware ist nicht aufwendig und auch die nötige Programmierung läßt sich einfach erledigen. 2. Konzept: Ein Netzwerkprotokoll verwenden, das über das Internet nicht geroutet wird, z.B. Class-A-Netzwerk (Netzwerkadresse ist nicht erreichbar). Die Adresse wird nach außen durch die Adresse des Firewallrechners, der zwischen Netz und Router geschaltet wird, ersetzt. Dafür muß sich der Firewall-Rechner die Realadressen zu jeder Verbindung merken, für nicht-verbindungsorientierte Protokolle (z.B. UDP, verwendet durch Nameserver, Nichtfunktionieren ist also sinnvoll; NFS, sehr unsichere Architektur, ergo Nichtfunktion gut; oder Real-Audio, was die Netzlast hochtreibt, also auch nicht erwünscht ist) aber nicht geeignet. Spoofing verbunden mit Flooding läßt sich von außen nicht abwehren. Es ist nur möglich, ein Netz von innen her abzusichern, indem man (z.B. als Provider) nicht Adressen des inneren Netzes nach außen senden läßt. Die Firewall hat hier aber immer noch die Schutzfunktion, daß im Falle des Falles nur die Firewall lahmgelegt wird, eine interne Netz-Kommunikation aber noch möglich ist. Um eine größtmögliche Sicherheit zu erreichen, sollte der Firewall-Rechner am einfachsten nach der Devise "was nicht erlaubt ist, ist verboten" verwaltet werden. So hat man die Sicherheit, daß nur die Prozesse ausgeführt werden können, die benötigt werden und auch vorgesehen sind. Gegen einen Teil von unerwünschten Zugriffen aus dem inneren Netz nach außen kann man sich auch durch Firewall-Proxies schützen. Während normalerweise ein Mailpaket in den Schichten zwei oder drei des 7-Schichtmodells (s. auch Artikel TCP/IP) im Router vom inneren in das äußere Netz gelangt, kann man dies unterbinden und über den Application-Layer (Schichten vier bis sieben) mit wenigen Code-Zeilen einen wirkungsvollen Filter aufbauen, der nicht nur nach den äußeren Paket-Kennungen (Absender, Empfänger, verwendeter Dienste-Port), sondern auch nach Inhalt filtern kann (keine Bilder, kein Real-Audio, kein Java, ausführbare Dateien werden vor dem Weitersenden auf Viren untersucht...). Ein Proxy hat neben den möglichen Filterfunktionen auch noch den Vorteil, daß oft verwendete Anfragen zwischengespeichert werden und damit nicht über das Netz geholt werden müssen. Gerade im HTTP-Bereich kann so viel unnötige Übertragung gespart werden. Firewall-Socks arbeiten nach einem ähnlichen Prinzip wie das Masquerading: Pakete werden mit der Socks-Adresse weiterverschickt, dies aber unter Unterstützung der Clients. Hierbei müssen die Clients "socksified" sein, d.h. die Applications müssen um Socks-Funktionalität erweitert sein. Nicht für alle Clients gibt es Socks-Versionen. Bei OS/2 Warp 4 wird inzwischen die Socks-Unterstützung auf Betriebssystem-Ebene umgesetzt, so daß die Clients es nicht mehr unterstützen müssen. Will man nun aber nicht ein Netz gegen die Umgebung abschließen, sondern sichere Netze z.B. über Internet miteinander verbinden, kommt man mit Firewalls nicht weiter - hier hilft ein weiteres Protokoll: das PPTP, das Point to Point Tunneling Protocol, mit dem für die Übertragungsstrecke über das Internet die Datenpakete noch einmal eingepackt werden, diesmal verschlüsselt, und am anderen Ende der Leitung werden sie einfach vom Header befreit und entschlüsselt und erhalten so ihre ursprüngliche Form wieder. Abschließend darf man den Referenten / Moderatoren für den gelungenen Workshop danken, da teils mit Beispielen aus dem menschlichen Leben eine sehr humorige Stimmung erreicht wurde und trotz der großen Menge an Teilnehmern mit den unterschiedlichsten Wissensständen (vom Anfänger bis zum Vollprofi war wirklich alles vertreten) die Gestaltung von Anfang bis Ende nicht langweilig wurde und jedem sicherlich noch interessantes Wissen vermittelt werden konnte. * Security in Open Systems (ca. 280 Seiten, Postscript), ftp://ftp.nist.gov/pub/csrc/nistpubs/800-8.ps * Firewalls (ca. 80 Seiten, Postscript), ftp://ftp.nist.gov/pub/csrc/nistpubs/800-10.ps Zusammenfassung von Derk Marko Reckel, Derk.Reckel@link-goe.de

[Datenschleuder] [58]    Firewalls - Aufzucht und Pflege